1. Field of the Invention
This invention relates in general to printing systems, and more particularly to a method, data structure and apparatus for providing object level rendering control using tagged secondary resources.
2. Description of Related Art
Documents use images, graphics and selected fonts to present their message more clearly. A printer file defines how application program output is mapped to each page and then printed. Rendering is the process a printer uses to translate the commands of a printer file to create an image. While the printer commands describe what the final page should look like, many do not describe how each object should be rendered. This extra rendering control consists of such calibration parameters as color correction points and halftone cell data.
Some printer command languages provide rendering controls that apply to all subsequent drawing commands. No existing printer command language provides rendering control for each object on a page. Many languages have no rendering control whatsoever. However, the need for rendering control continues to increase.
For example, as the use of color input, display and output devices increase, so does the need for color management to ensure document colors appear the same in all devices. This is due to several factors. For example, differing device types operate in different color spaces. A color space is a model for representing color in terms of intensity values; a color space specifies how color information is represented. A color space defines a one-, two-, three-, or four-dimensional space whose dimensions, or components, represent intensity values. A color component is also referred to as a color channel. For example, RGB space is a three-dimensional color space whose components are the red, green, and blue intensities that make up a given color. For example, color monitors display colors as combinations of red, green and blue, and are said to work in the RGB color space, Printers, however, generally print images as combinations of cyan, magenta, yellow and black, and are said to work in the CMYK color space.
Different color devices have different color capabilities. Every color device, such as a scanner, printer or monitor, has a range of colors that it can produce, which is often referred to as a gamut.
In addition, devices of the same type that are manufactured by different manufacturers may produce different colors for the same object. Also, the gamut that an ink jet color printer can print may be quite different from a printer based on a different technology such as a color laser printer.
Some color spaces can express color in a device-independent way. Whereas RGB colors vary with display and scanner characteristics, and CMYK colors vary with printer, ink, and paper characteristics, device-independent colors are meant to be true representations of colors as perceived by the human eye. These color representations, called device-independent color spaces, result from work carried out in 1931 by the Commission Internationale d'Eclairage (CIE) and for that reason are also called CIE-based color spaces.
The most common method of identifying color within a color space is a three-dimensional geometry. The three color attributes, hue, saturation, and brightness, are measured, assigned numeric values, and plotted within the color space. RGB colors vary with display characteristics, and CMYK colors vary with printer, ink, and paper characteristics. Conversion from an RGB color space to a CMYK color space involves a number of variables. The type of printer or printing press, the paper stock, and the inks used all influence the balance between cyan, magenta, yellow, and black. In addition, different devices have different gamuts, or ranges of colors that they can produce. Because the colors produced by RGB and CMYK specifications vary from device to device, they're called device-dependent color spaces. Device-dependent color spaces enable the specification of color values that are directly related to their representation on a particular device.
Device-independent color spaces, or interchange color spaces, are used to convert color data from the native color space of one device to the native color space of another device. The CIE created a set of color spaces that specify color in terms of human perception. It then developed algorithms to derive three imaginary primary constituents of color—X, Y, and Z—that can be combined at different levels to produce all the color the human eye can perceive. The resulting color model, CIE X, Y, Z and other CIE color models form the basis for all color management systems. Colors can be specified in the CIE-based color spaces in a way that is independent of the characteristics of any particular display or reproduction device. The goal of color management is for a given CIE-based color specification to produce consistent results on different devices, up to the limitations of each device.
CIELuv is a CIE-based color space used in additive color systems, including color lights and emissive phosphor displays. CIELab is a CIE-based color space that is often used as a device-independent color space in printing applications.
Color matching typically means converting colors between differing gamuts. Most current color management systems match colors pursuant to a rendering intent. Objects are anything that can be drawn, and include text, graphics, and raster images. Usually, a document containing objects is printed using a rendering intent for the whole document. Some printers have been equipped with a console control to control the rendering for each job. Yet, a control console will not allow a page containing different types of objects to have each of the objects rendered individually.
Print systems include presentation architectures, which are provided for representing documents in a data format that is independent of the methods utilized to capture or create those documents. One example of an exemplary presentation system, which will be described herein, is the AFP™ (Advanced Function Presentation) system developed by International Business Machines Corporation. However, those skilled in the art will recognize that the present invention is not meant to be limited to the AFP™ system, but rather the AFP™ system is presented herein as merely one example of a presentation system applicable to the principles of the present invention.
According to the AFP™ system, documents may contain combinations of text, image, graphics, and/or bar code objects in device and resolution independent formats. Documents may also contain and/or reference fonts, overlays, and other resource objects, which are required at presentation time to present the data properly. Additionally, documents may also contain resource objects, such as a document index and tagging elements supporting the search and navigation of document data for a variety of application purposes. In general, a presentation architecture for presenting documents in printed format employs a presentation datastream. To increase flexibility, this stream can be further divided into a device-independent application datastream and a device-dependent printer datastream.
A datastream is a continuous ordered stream of data elements and objects that conform to a given formal definition. Application programs can generate datastreams destined for a presentation device, archive library, or another application program. The Mixed Object Document Content Architecture (MO:DCA)™ developed by International Business Machines Corporation of Armonk, N.Y. defines a datastream, which may be utilized by applications to describe documents and object envelopes for document interchange and document exchange with other applications and application services. Interchange is the predictable interpretation of shared information in an environment where the characteristics of each process need not be known to all other processes. Exchange is the predictable interpretation of shared information by a family of system processes in an environment where the characteristics of each process must be known to all other processes.
A mixed object document is a collection of data objects that comprise the document's content and the resources and formatting specifications that dictate the processing functions to be performed on that content. The term “Mixed” in the Mixed Object Document Content Architecture (MO:DCA)™ refers to both the mixture of data objects and the mixture of document constructs that comprise the document's components. A Mixed Object Document Content Architecture (MO:DCA)™ document can contain a mixture of presentation objects types, which each have a unique processing requirement. The Mixed Object Document Content Architecture (MO:DCA)™ is designed to integrate the different data object types into documents that can be interchanged as a single datastream and provides the datastream structures needed to carry the data objects. The MO:DCA™ datastream also provides syntactic and semantic rules governing the use of objects to ensure different applications process objects in a consistent manner.
In its most complex form a Mixed Object Document Content Architecture (MO:DCA)™ document contains data and resource objects along with data structures which define the document's layout and composition features. This form is called a Mixed Object Document Content Architecture (MO:DCA)™ presentation document. Within such a datastream the Mixed Object Document Content Architecture (MO:DCA)™ components are defined with a syntax that consists of self-describing structures called structured fields. Structured fields are the main Mixed Object Document Content Architecture (MO:DCA)™ structures and are utilized to encode Mixed Object Document Content Architecture (MO:DCA)™ commands. A structured field starts with an introducer that uniquely identifies the command, provides a total length for the command, and specifies additional control information such as whether padding bytes are present. The introducer is then followed by data bytes. Data may be encoded within the structured field utilizing fixed parameters, repeating groups, key words, and triplets. Fixed parameters have a meaning only in the context of the structure that includes them. Repeating groups are utilized to specify grouping of parameters that can appear multiple times. Key words are self-identifying parameters that consist of a one byte unique key word identifier followed by a one byte keyword value. Triplets are self-identifying parameters that contain a length field, a unique triplet identifier, and data bytes. Key words and triplets have the same semantics wherever they are utilized. Together these structures define a syntax for Mixed Object Document Content Architecture (MO:DCA)™ datastreams which provide for orderly parsing and flexible extendibility.
The document is the highest level within the Mixed Object Document Content Architecture (MO:DCA)™ datastream document component hierarchy. Documents may be constructed of pages, and the pages, which are at the intermediate level, may be made up of data objects. Data objects are at the lowest level and can be bar code objects, graphics objects, image objects and presentation text.
Multiple documents may be collected into a print file. A print file may optionally contain, at its beginning, an “inline” resource group that contains resource objects required for print. Alternatively, the resource objects may be stored in a resource library that is accessible to the print server, or they may be resident in the printer.
A Mixed Object Document Content Architecture (MO:DCA)™ document in its presentation form is a document which has been formatted and is intended for presentation, usually on a printer or a display device. A datastream containing a presentation document should produce the same document content in the same format on different printers or display devices, dependent on the capabilities of each of the printers or display devices. A presentation document can reference resources that are to be included as part of the document to be presented, which are not present within the document as transmitted within the MO:DCA™ datastream.
Pages within the Mixed Object Document Content Architecture (MO:DCA)™ are the level within the document component hierarchy which is utilized to print or display a document's content. Each page has associated environment information that specifies page size and that identifies resources required by the page. This information is carried in a MO:DCA™ structure called an Active Environment Group (AEG). Data objects contained within each page envelope in the datastream are presented when the page is presented. Each data object has associated environment information that directs the placement and orientation of the data on the page, and that identifies resources required by the object. This information is carried in a MO:DCA™ structure called an Object Environment Group (OEG). Note that a Resource Environment Group (REG) may be included for identifying resources prior to printing. The REG is specified at the beginning of a document or job, or on any page boundary in a document or job, and identifies complex resources that are required by the pages that follow.
Delimiters that identify the object type, such as graphics, image or text, bound objects in the datastream. In general, data objects consist of data to be presented and the directives required to present it. The content of each type of data object is defined by an object architecture that specifies presentation functions, which may be utilized within its coordinate space. All data objects function as equals within the Mixed Object Document Content Architecture (MO:DCA)™ datastream environment. Data objects are carried as separate entities in the Mixed Object Document Content Architecture (MO:DCA)™ datastream.
Resource objects are named objects or named collection of objects that can be referenced from within the document. In general, referenced resources can reside in an inline resource group that precedes the document in the MO:DCA™ datastream or in an external resource library and can be referenced multiple times. Resource objects may need to be utilized in numerous places within a document or within several documents.
An object container within the Mixed Object Document Content Architecture (MO:DCA)™ is an envelope for object data that is not necessarily defined by an International Business Machines Corporation presentation architecture and that might not define all required presentation parameters. The container consists of a mandatory Begin/End structured field pair, an optional Object Environment Group (OEG) and mandatory Object Container Data (OCD) structured fields. If an object is to be carried in Mixed Object Document Content Architecture (MO:DCA)™ resource groups and interchanged, it must, at a minimum, be enveloped by a Begin/End pair. The Object Classification triplet on the Begin structured field must specify the registered object identifier (OID) for the object data format, and the data must be partitioned into OCD structured fields.
A printer datastream within a presentation architecture is a device-dependent continuous ordered stream of data elements and objects conforming to a given format, which are destined for a presentation device. The Intelligent Printer Datastream (IPDS)™ architecture developed by International Business Machines Corporation and disclosed within U.S. Pat. No. 4,651,278, which is incorporated herein by reference, defines the datastream utilized by print server programs and device drivers to manage all-points-addressable page printing on a full spectrum of devices from low-end workstation and local area network-attached printers to high-speed, high-volume page printers for production jobs, Print On Demand environments, shared printing, and mailroom applications. The same object content architectures carried in a MO:DCA™ datastream are carried in an IPDS™ datastream to be interpreted and presented by microcode executing in printer hardware. The IPDS™ architecture defines bi-directional command protocols for query, resource management, and error recovery. The IPDS™ architecture also provides interfaces for document finishing operations provided by pre-processing and post-processing devices attached to IPDS™ printers.
The IPDS™ architecture incorporates several important features. As noted above, since the IPDS™ architecture supports the same objects as those carried by the MO:DCA™ datastream, the IPDS™ architecture enables the output of multiple diverse applications to be merged at print time so that an integrated mixed-data page, including text, images, graphics, and bar code objects, results. The IPDS™ architecture transfers all data and commands through self-identifying structured fields that describe the presentation of the page and provide for dynamic management of resources, such as overlays, page segments and fonts as well as the comprehensive handling of exception conditions. Furthermore, the IPDS™ architecture provides an extensive acknowledgement protocol at the datastream level, which enables page synchronization of the host (e.g., print server) and printer processes, the exchange of query-reply information, and the return to the host of detailed exception information.
Sophisticated datastreams allow the inclusion of heterogeneous objects on a page. These objects contain data to be rendered, but the data are not described using the primary datastream of the job. They are instead described using a different standard datastream, an earlier version of the primary datastream, or a device-dependent datastream. For example, an AFP print job may contain a TIFF image object, a PostScript (P/S) Level 2 print job may contain a PostScript Level 1 EPS graphic, a PDF print file may contain a device-dependent RGB image tuned for a particular display, and so on. While it is possible to render these heterogeneous objects using their own datastreams, it is sometimes desirable to allow the primary datastream to affect the rendering of these objects, generally because the primary datastream specifies more rendering control than the objects' datastreams do.
For example, color images in PostScript Level 1 are specified only in device-dependent CMYK, and users identify which of the standard CMYK color spaces the renderer should use (such as SWOP or Euroscale) outside the PostScript Level 1 datastream, through machine settings. Thus, PostScript Level 1 renderers must assume that all CMYK images are from the same color space (all SWOP, for example, or all Euroscale), but not a mixture.
Moreover, AFP can include PostScript Level 1 color images as heterogeneous objects on an AFP page. Such objects are passed to a P/S renderer for processing. The P/S renderer can apply a different color space to each image and so could support a mixture of SWOP and Euroscale images on the page. However, the object content sent to the P/S renderer is pure PostScript Level 1 and cannot identify which color space should be applied.
Another illustration involves images that are tuned to a particular device, such as device RGB data within a PDF file. The color quality of that RGB image is only exact when the PDF file is displayed on the device it was tuned for (typically the author's monitor). When printed, the RGB representation will be converted to printer's colorants assuming some RGB calibration, which probably will not match the author's monitor, and so the printed image will have its colors shifted from the original, perhaps significantly. A sophisticated PDF renderer might be able to adjust its RGB calibration to more closely match the original, but RGB data has no way to communicate the source calibration parameters. Yet another instance of the problem involves images that are tuned to a particular halftoning algorithm.
In the example that follows, the data object is a P/S level 1 EPS object that is carried in an AFP (MO:DCA-P) datastream and that is tagged with a CMYK profile. Presentation data objects, such as P/S level 1 objects and raster image objects, that specify color using the CMYK color space, are inherently device-dependent. That is, when the CMYK is rendered on a marking engine, the resultant color is dependent on a number of printer-specific parameters such as print technology and toner/ink. On the other hand, specifying colors using CMYK is convenient since, in general, no color transformations are required to render these colors on a printer, therefore these objects tend to print fast. Before device-independent color spaces (such as CIELab) and color management systems came into use in the early 1990s most data intended for printing specified color using the CMYK color space. This is particularly true with PostScript Level 1 files.
To achieve somewhat consistent rendering of CMYK colors, a number of CMYK color standards were developed. These standards basically defined hypothetical offset presses that rendered a given CMYK value with a pre-defined color. The pre-defined colors and their associated CMYK values were then published using a large set of color swatches. Two examples of such press standards are CMYK SWOP and CMYK Euroscale.
There exists much presentation data, particularly PostScript Level 1 data, that is ‘tuned’ to one of these defacto standards. In the AFP presentation environment such data can be mixed with other AFP data on a page and needs to be rendered appropriately. This can be a problem since, for a given page, there may be CMYK data that is tuned to SWOP, CMYK data that is tuned to Euroscale, and CMYK data that is just tuned for the particular printer. That is, the particular CMYK flavor is an object level attribute that can be different for each object on a page.
As mentioned above, a control console has been used to select the rendering on some printers. For example, the Infoprint Color 100 PostScript printer uses an operator-controlled console switch. The clear drawback to this solution is that it assigns a specific CMYK attribute to the whole print job, not to individual objects on a page in the job. While rendering control has been described primarily using examples of color management and AFP datastreams, those skilled in the art will recognize that the present invention is not meant to be limited to only this rendering control or only this primary datastream.
It can be seen then that there is a need for a method, data structure and apparatus for providing object level management using tagged secondary resources.
It can also be seen then that there is a need for a method, data structure and apparatus that can apply the AFP color space capability (allowing a mixture of color spaces on a page) to objects (that can't distinguish different CMYK color spaces) without modifying the object content.